Strengthening Indian Land Governance: Enhancing Transparency through DPoS Blockchain Registry

Abstract

In India, where conventional Land Registry systems encounter challenges, Land Registry documents are crucial legal evidence of land ownership. Addressing these issues requires innovative solutions, and Blockchain technology offers a key solution. Our approach focuses on refining the Delegated Proof of Stake (DPoS) consensus, introducing a private ledger system for secure land asset transactions. Specifically designed for integration into India\'s existing Land Registry framework, our system ensures seamless and efficient operations. This novel solution leverages Blockchain to establish a transparent and secure digital ledger, providing a reliable means of recording land asset information in the country\'s real estate landscape.

Introduction

I. INTRODUCTION

Our innovative proposal presents a distinctive approach to digitize the land registry documentation process in India, ensuring the security of these documents. Utilizing blockchain technology in the land registry, information related to land assets is securely stored in a private ledger, interconnected through cryptographic hashes. Our solution builds upon existing land registry systems, integrating blockchains with Delegated Proof of Stake consensus protocols. This seamless integration facilitates compatibility with traditional systems, ensuring data transparency and immutability. The incorporation of decentralized levels, dividing the land into zones with selected operating nodes, mitigates the need for node competition in computationally complex puzzles. Consequently, this approach conserves computational power, enhancing overall energy efficiency for the system and making counterfeiting and forging arduous tasks, thereby preventing potential attacks.

II. RELATED WORKS

A.  Land Registry documentation of INDIA—

Land Registry documentation in India follows a specific set of information essential for recording land details. In the  context of the Indian land registry process, the document must include the following particulars:

1. Tehsil: Signifying the region where the land is situated.
2. Gram Number: This unique identifier corresponds to a document that specifies details about a particular Gram inside the Tehsil of any District in India.
3. Khasra number / Basra Number: This unique identifier corresponds to a document that specifies details about a particular parcel of land.
4. Rakba Number: This unique identifier corresponds to a document that specifies details about a particular parcel of land in Hectare.
5. Khatauni Number: Khatauni, a vital land document, reveals land-holding details within a family, encompassing khasra numbers, ownership count, total area, etc. Obtainable at village tehsils, Jan-Suvidha centers, or state revenue department websites, it's conveniently accessible online via Bhulekh portals.
6. Jamabandi: This document verifies the payment of government taxes related to the specific land parcel.
7. Record of Rights (RoR): A document substantiating the ownership of a piece of land by an individual.
8. Khata Number: This Document encapsulates the historical records of all prior landowners, providing a comprehensive   Ownership history.

TABLE 1 —    LAND INFO PORTAL OF VARIOUS STATES OF INDIA

Description of Table 1 :  The table presents an extensive compilation of official land information portals catering to various states in India, along with their corresponding official titles and portal links. These platforms serve as centralized hubs for accessing a plethora of land-related data, including records, property particulars, ownership details, and associated documents. Governed by the respective state authorities or revenue departments, these portals are instrumental in digitizing land records, streamlining administrative processes, and fostering transparency in land management.

Each state boasts its dedicated portal, such as Meebhoomi for Andhra Pradesh, Dharitree for Assam, and Bhulekh for Bihar, among others. These portals serve as pivotal tools in modernizing land records, mitigating bureaucratic hurdles, and enhancing overall operational efficiency in land governance. Individuals ranging from landowners to potential buyers and sellers can leverage these platforms to verify land ownership, ascertain property specifics, initiate land transactions, and procure essential documentation.

By offering convenient online access to land-related information, these portals contribute significantly to the digitization of land records, broadening accessibility, and minimizing reliance on cumbersome paperwork. In essence, they signify a crucial stride towards modernizing land administration practices and fostering a conducive environment for real estate activities, ultimately bolstering ease of doing business in the sector.

B. Challenges in Traditional Land Registry

1. Intermediaries, Agents: In business, intermediaries and agents play a pivotal role, possessing valuable market knowledge. Buyers and sellers, lacking in-depth understanding, often turn to these intermediaries for insights into market dynamics and pricing. However, their involvement can introduce errors in land documents, given their role in real estate transactions. The process becomes costlier due to the engagement of various stakeholders, including local authorities, agents, lenders, and intermediaries.
2. Fraudulent Activities: India faces numerous cases of impostors posing as legitimate land or property sellers. Successful impersonation leads to fund misappropriation, often remaining unnoticed by both sellers and buyers until discovered during land registry spot checks.
3. Prolongated Process Time: The Land Registry process in India requires approximately two to three months for completion, from transaction conclusion to registration.
4. Human Errors/Interventions: Human involvement increases the risk of errors in the land registry process, making it more susceptible to inaccuracies and systemic flaws.

C. Evolution Of BlockChain —

The structures of various Blockchain systems may appear similar but differ in their consensus protocols crucial for governing the Blockchain and meeting preset conditions for block mining and chain addition. Proof of Work initially proposed by Adam Back in Hashcash - A Denial of Service Counter-Measure [1] and popularized by Satoshi Nakamoto in Bitcoin – A Peer-to-Peer Electronic Cash System [2] requires substantial resources for block creation verification.

To address this Proof of Stake emerged as an alternative necessitating users to demonstrate ownership of a specific amount of currency as seen in examples like PP-coin – Peer-to-Peer Crypto-Currency with Proof-of-Stake [3] by Sunny King and Scott Nadal. However vulnerabilities like Nothing at Stake [4] and Fake Stake [5] attacks were identified. Delegated Proof of Stake enhances the Proof of Stake model by incorporating democratic principles through elections and voting offering scalability and speed throughout network development stages[6]. Nonetheless, it remains susceptible to user lobbying for votes potentially electing an attacking delegate or undermining the significance of votes in elections [7].

III.  PROPOSED SYSTEM ARCHITECTURE

Our solution for land registry introduces an original approach, employing the Delegated Proof of Stake consensus structure to prevent the inefficient use of computational resources and thwart 51% attacks [8]. In our envisioned model, we incorporate the participation of financial institutions engaged in land registry transactions to ensure transparency and prevent the concentration of network control within a single entity. This is crucial for averting the risk of a Majority attack that might arise in a system where Land Registry authorities hold complete control. Our system operates without generating block rewards or functioning as a currency. It seamlessly integrates with the traditional land registry system, where financial institutions handle transactions involving the purchase and sale of land assets using regular currency in their local regions. This facilitates a smooth transition to a digital system [9]. We introduce an innovative Council Protocol, an enhancement over Delegated Proof of Stake, by introducing randomization in the election process and eliminating the use of lobbying votes [6]. Additionally, we implement value ranges for computing cryptographic puzzles, allowing the distribution of workload among multiple nodes with distinct ranges of values. This enhances computational efficiency, minimizing the waste of computational power.

A. Block Structure

We have designed a customized block structure for the private ledger of our system, ensuring seamless integration with the existing physical information structure used for Land Registry purposes in India. While adhering to the standard block structure of a Blockchain, we have introduced a Target Range, deviating from the typical Lower Hash Target Limit found in standard Blockchains. Within our consensus protocol, Miners are assigned a Start Value and End Value, allowing them to mine within a specified range when the workload is distributed among them.

TABLE II.     MAIN STRUCTURE OF A BLOCK

TABLE III.     STRUCTURE INSIDE BLOCK DATA

TABLE IV.      SPECIFIES TABLE IN BLOCK

B. Node Hierarchy

In the envisioned model, the system architecture is organized into a three-layer hierarchy . Hierarchical models introduce a form of authoritative control, somewhat constrained by the consensus protocol. The responsibilities of the three proposed nodes are outlined as follows:

1. Computational Nodes:  These are ordinary mining computers tasked with mining a block upon receiving a mine command from the Council Node. Local land registry authorities will oversee the control of these computers.
2. Information Nodes:    Positioned above Computational Nodes in the hierarchy, Information Nodes are larger servers with increased storage and computational capabilities. Their role includes storing comprehensive transaction information, relaying commands from the Council Node to Computational Nodes, validating transaction information, and verifying transaction requests before transmission to the Council Node. These servers also contribute to maintaining the consensus protocol among all nodes within the zone, ensuring the chain's integrity. Financial institutions involved in land transactions will manage and control the Information Nodes. Data input is facilitated through a Distributed Application (DApp) hosted by the Council Nodes. Due to the potential diversity of participating financial institutions as Information Nodes, the data provided by each node is sensitive and encrypted, ensuring invisibility from one another to uphold security.
3. Council Nodes: In each zone, government authorities exercise control over a singular Council Node. These Council Nodes within each zone are interconnected with those of other zones and the Information Nodes within their respective zones. The primary function of this node is to authorize the mining of a block whenever a transaction is reported, directing the remaining nodes in its zone to commence mining based on the provided information. Additionally, upon receiving a mine request, it disseminates the information to other Council Nodes in different zones to ensure secure storage and cross-verification, guarding against potential tampering during block mining. Council Nodes are tasked with maintaining comprehensive transaction records for each zone, crucial for upholding the consensus protocol among the Master Nodes in each zone. Hosting the Distributed Application (DApp), Council Nodes serve as the entry point for all information input and transaction requests. Drawing a parallel with a general Delegated Proof of Stake (DPoS) system, Council Nodes resemble Delegates by voting for the node responsible for mining the block.

IV.  ARCHITECTURAL CONSTRAINTS & SCALABILITY

Due to the three-levelled hierarchy in the proposed system architecture and the necessity for an uneven number of nodes to achieve successful Byzantine Fault Tolerance [10], a minimum number of nodes is required to implement and scale this architecture effectively. The successful implementation of this architecture mandates a minimum of thirty-nine (39) nodes in the basic structure, distributed across three zones.

To calculate the minimum architecture, attention must first be given to the random election process. For such an election to transpire, a minimum of 3 council nodes is necessary, as odd numbers above 1 are essential for ensuring a successful election each time. Each zone in the architecture adheres to the following node structure:

• One (1) Council Node.
• Three (3) Information Nodes under the council node.
• Nine (9) Computational Nodes, with three (3) Computational Nodes under each Information Node.

The scalability of this architecture can unfold in one of three ways:

• Incrementing Councils: To scale zone-wise, two zones with the minimum architecture must be added to the existing setup.
• Incrementing Information: For scalability using Information nodes, precisely four (4) nodes need to be added under any of the Council Nodes. One (1) will be an Information Node, while the other three (3) nodes will be Computational Nodes.
• Incrementing Computes: To scale using Computational Nodes, exactly two (2) Computational Nodes should be added under any of the Information nodes in any order with each scaling.

V. COUNCIL PROTOCOL

Considering the challenges of the Traditional Land Registry system, Blockchain structures, and the proposed system architecture, conventional consensus protocols prove inadequate for addressing the identified issues. The envisioned Council Protocol encompasses all the aforementioned aspects, integrating components of the

Consensus Protocol. This innovative approach aims to overcome existing problems, ensure data immutability, and introduce a new dimension of authorized accessibility to data.

A. Democratic Consortium

Establishing a democratic system within a predefined consortium is a challenge addressed by the Council Protocol. This protocol designates fixed members of the consortium as Council Nodes, responsible for electing miners, ensuring democratic functionality. By maintaining predefined roles, the protocol ensures system integrity and stability. Council Nodes, representing consortium members, participate in electing the Computational Node for specific block mining, promoting transparency and fairness.

The Council Protocol's reliance on Council Nodes preserves the consortium's predetermined structure while facilitating democratic decision-making. This approach fosters trust and collaboration among members, enhancing system credibility. Moreover, the protocol includes safeguards to prevent undue influence or manipulation in the election process, ensuring equal voting rights and transparency.

Overall, the Council Protocol establishes and upholds democratic principles within the consortium, empowering Council Nodes to elect miners and make decisions transparently. This ensures fair and unbiased block mining, fostering trust and cooperation among members while maintaining system integrity.

???????B. Tiered Random Election/Delegation

The Council Protocol introduces a proactive measure to randomize the election/delegation process, preventing vote lobbying or withdrawal from the voting process . In the election process, the Council Node receiving the transaction request generates a randomized array of n - 1 zones (where n is the total number of zones) and proposes this array to other Council Nodes. Each Council Node then randomly elects a member of the array. If the election results in a majority for any zone, the next election proceeds; otherwise, the initial Council Node removes one zone and repeats the first-tier election until a majority zone is elected.

After completing the first-tier election, the second tier begins. The initial Council Node generates a randomized array of [m - 1] Information Nodes (where m is the total number of Information Nodes under the Council Node of the elected zone). The second-tier election mirrors the first tier, leading to the third tier, where candidates are a randomized array of [p - 1] Computational Nodes under the elected Information Node. These nodes are elected similarly to the first and second-tier elections. The resulting Computational Node, after the three-tiered genetic election, is delegated to mine the block for the incoming request. The elected Computational Node receives data for the block, including a timestamp and a randomly generated difficulty/upper limit.

???????C. Consent-based Mining

After receiving data from the initial Council Node, the elected Computational Node conducts tests to verify the chain's integrity and updates it in case of corruption. It generates a randomized list of nodes, excluding itself, numbering between (x / 50 + 1) to (x * 0.75), where x is the total number of nodes. The listed nodes are then requested to send the hash of the latest block in their chain. The elected Computational Node compares its own latest hash to the majority chain and rectifies any discrepancies by adopting the majority's chain. Subsequently, it mines the data within a designated timeframe, sending the mined block to the controlling Information Node for validation. The block is then re-validated by the Information Node, initiating the chaining protocol.

D. Sub-zone Locking

If the elected Computational Node fails to mine within the allotted time, it sends the final nonce to its controlling Information Node, triggering a subzone lock. The subzone includes the elected Computational Node's Information Node and its sibling Computational Nodes. The subzone's Information Node informs its Council node to lock the subzone, excluding it from any election until the current block is mined. Simultaneously, the Information Node transforms from a witness to a miner, directing all Computational Nodes under it to mine the block at non-overlapping nonce ranges. Once any node within the locked subzone successfully mines the block, the Information Node resumes normal chaining, unlocking the subzone.

During subzone locking, if any nodes are busy, the Information Node finds a free subzone across all zones, locking it until the block is successfully mined.

E. Chaining Protocol

The chaining protocol initiates at the Information Node of the elected Computational Node or subzone. The Information Node validates the nonce and hash. If invalid, it requests further mining; if valid, it requests database locking for all nodes with a timestamp to prevent race conditions. After confirming the database lock, the Information Node requests adjoining nodes to add the mined block to their chains. Nodes receiving the request update their chains, and if mining, their referenced previous hash changes. Once all nodes comply with the chaining command, the Information Node requests unlocking databases for normal processes to resume.

Conclusion

Implementing Blockchain technology in the existing Land Registry system for registration and verification purposes can provide the following benefits : A. The time required for the land transaction process would be significantly reduced to a few days instead of months. B. Ownership verification becomes accurate and rapid. C. The system becomes entirely digital, eliminating the need for extensive paperwork. D. All documentation is registered into the Blockchain during transactions/registrations, ensuring no missing documents. E. The system offers high security, effectively preventing fraud. The manual nature of the Land Registry process in India is inherently rigorous. By digitizing this process and utilizing Blockchain to store transactions and documents, we enhance the system\'s transparency, simplify procedures, bolster security, and expedite processing.

References

[1] Back, A. (2002). Hashcash - A Denial of Service Counter-Measure. Retrieved from http://www.hashcash.org/papers/hashcash.pdf [2] Nakamoto, S. (2008). Bitcoin: A Peer-to-Peer Electronic Cash System. Retrieved from https://bitcoin.org/bitcoin.pdf [3] King, S., & Nadal, S. (2012). PPCoin: Peer-to-Peer Crypto-Currency with Proof-of-Stake. Retrieved from https://peercoin.net/assets/paper/peercoin-paper.pdf [4] Bentov, I., Lee, C., Mizrahi, A., Rosenfeld, M. (2016). The Proof of Stake ‘Vulnerability’. Retrieved from https://eprint.iacr.org/2016/889.pdf [5] Aviv, A., Seeman, N., Shapiro, B., & Zohar, A. (2018). Security of Stake in the Fake Stake Attack. Retrieved from https://arxiv.org/abs/1812.08328 [6] Larimer, D. (2014). Delegated Proof-of-Stake (DPoS) - A New Consensus Algorithm for Blockchain. Retrieved from https://bytemaster.github.io/2015/07/09/delegated-proof-of-stake/ [7] Ren, Z., Ma, Z., Sun, H., & Sun, Y. (2020). Blockchain and Smart Contract Based Approach for Land Registration and Management. IEEE Access, 8, 174727-174735. DOI: 10.1109/ACCESS.2020.3022179 [8] Zheng, Z., Xie, S., Dai, H., Chen, X., & Wang, H. (2018). An Overview of Blockchain Technology: Architecture, Consensus, and Future Trends. In IEEE International Congress on Big Data (BigData Congress), 2017 (pp. 557-564). DOI: 10.1109/BigDataCongress.2017.85 [9] Tapscott, D., & Tapscott, A. (2016). Blockchain Revolution: How the Technology Behind Bitcoin Is Changing Money, Business, and the World. Penguin. [10] Lamport, L., Shostak, R., & Pease, M. (1982). The Byzantine Generals Problem. ACM Transactions on Programming Languages and Systems (TOPLAS), 4(3), 382-401. DOI: 10.1145/357172.357176

Copyright

Copyright © 2024 Ayush Diwakar, Lokesh Kumar Sahu, Samiksha Shukla. This is an open access article distributed under the Creative Commons Attribution License, which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited.